In P2P computer networks, peer nodes (or peers) cooperate to deliver data content to one another. The diverse connectivity and the cumulative bandwidth of the peers is used for sharing data content such as, for example, files containing audio, video, data or anything in digital format, telephony traffic, video streaming or video download. A P2P network can, in many cases, provide a much more efficient distribution of data content than a hierarchical network topology with a relatively low number of centralised servers providing data content to end nodes. In a pure P2P network there is no notion of clients or servers, but only of equal peers. There are, however, many types of hybrid P2P networks which combine a client-server structure with the P2P structure, since different network structures may be preferred for different types of tasks. Hereinafter the term “P2P network” is intended to encompass both pure P2P networks and hybrid P2P networks.
There is a number of different protocols that may be used for P2P communication. Examples include BitTorrent, Gnutella, CAN, FastTrack, and JXTA. The BitTorrent protocol is one of the most widely used P2P protocols and is described in “The BitTorrent Protocol Specification”, version 11031, by Cohen, Bram, last edited 28 Feb. 2008, available at http://www.bittorrent.org/beps/bep_0003.html.
In a P2P system a tracker is a software server application that centrally coordinates the P2P communication among users. Tracker software manages torrent swarms to be used by peers—a torrent swarm essentially contains information about clients interested in a content. Specifically, the tracker identifies the IP address of each client either uploading or downloading the content associated with a torrent.
BitTorrent clients connect to a tracker specified in the torrent file in order to join a swarm. The tracker sends to the client (peer) a list of peers that are part of the swarm, and from that point on most of the interaction happens between clients. Clients will send messages of interest, exchange bit maps, and finally requests for given content chunks. However, it must be noted that the list of peers initially obtained from the tracker is of major importance—those are the peers that will be used for downloading content. Thus the tracker performs a central role in the BitTorrent model.
The original BitTorrent architecture uses one or a set of trackers in which BitTorrent clients (peers) connect in order to request a list of potential sources in a swarm. When a BitTorrent client joins a swarm, the tracker responds with a list of randomly selected peers. By default, the number of peers in the list is 50 peers. A BitTorrent client can utilize several trackers that have the same content by joining each swarm managed by them. If there are multiple trackers for the same content, each tracker manages one swarm of that content. Subsequently, the BitTorrent client applies standard BitTorrent policies (optimist unchoking, rarest first, buffer emptiness prioritization) to choose the peers, obtain the content and share the acquired content parts. Even though a list of 50 peers is received from the tracker, the default simultaneous number of peers used to acquire the content is four.
A well-known problem related to the BitTorrent architecture is the lack of locality awareness. That is, a client who joins a swarm will receive a list of peers that is randomly selected by the tracker. A client may download content from peers that are very distant network wise, even though many peers nearby (network wise) have the same content. Some solutions to this problem utilize databases of IP geo location to create locality awareness. These solutions are not very accurate since these databases contain errors and, most importantly, geographical distance does not imply network distance.
Furthermore, the tracker does not take into account the usage of the network resources when selecting the peers on behalf of a client. Since the client chooses other peers out of the list obtained from the tracker based on the standard BitTorrent policies (which are intended to incentive the content sharing and keep the content available on the swarm), network resources are often sub-optimally utilized.
The tracker model for delivery of P2P content is far from ideal for utilization in a managed operator network, since the operator does have a lot of information about network topology and current network load on links. When an operator utilizes P2P techniques for delivery of VoD or time shift content (as described, for example, in WO 2009/152865) it must ensure a given download rate and consequently playback continuity. This cannot be achieved using existing tracker techniques.
Work being standardized in IETF (described in ALTO WG, Application Layer Traffic Optimization Working Group, http://tools.ietf.org/wg/alto/ and “P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers”, Haiyong Xie, Arvind Krishnamurthy, Avi Silberschatz, Y. Richard Yang) tries to solve the locality question by utilizing a tracker that has more knowledge about the network and the peers. One possible approach is to create an enhanced tracker that receives three different inputs to compile a peer list: current network load, network topology and peer content availability. A list of peers can be calculated based on operator policies together with these three inputs.
However, such a tracker will very quickly suffer scalability problems. The number of content assets to be managed, the number of clients participating in a swarm and the size of the network will put very high strain on such a tracker.
In addition, to keep the protocol simple the BitTorrent tracker does not know which peers contain specific parts of the content (blocks) in the swarm. It is therefore possible that the peer list returned to a client contains peers that do not have the desired parts of the content. The effort wasted by communicating with unusable peers could affect the quality of the service.